Spring4Shell Vulnerability vs Log4Shell Vulnerability

On March 29, 2022, details of a zero-day vulnerability in Spring Framework (CVE-2022-22965) were leaked. For many, this is reminiscent of the zero-day vulnerability in Log4j (CVE-2021-44228) back in December 2021.   

What is the difference between the vulnerabilities?  

The Spring Framework vulnerability was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.   

On the other hand, the Log4j vulnerability was the result of an exploitable logging feature. If the logging feature is successfully exploited on your infrastructure, attackers can perform an RCE (Remote Code Execution) attack and compromise the affected server. 

What is the scope of the vulnerabilities?  

Since we are a cloud-based Software Composition Analysis (SCA) provider, we are able to leverage data on the scope of the vulnerabilities.   

As we mentioned in December, 95 percent of our enterprise customers – organizations with over 100 applications – use Java.  Of those enterprise customers using Java, 88 percent use some version of Log4j, the most popular being version 1.2. 

​

When it comes to Spring Framework, we found that 55 percent of Java applications leverage some form of Spring Beans, most using version 5.3.  

So how many enterprise customers using Java leverage vulnerable versions of Log4j or Spring Beans? Well, for Log4j, we found that 58 percent are using a vulnerable version. For Spring Beans, the number is higher, 89 percent. One reason that the number is higher for Spring Beans is because older, non-vulnerable versions of Spring Beans (e.g., version 2.x) are rarely used anymore. However, older, non-vulnerable versions of Log4j (e.g., version 1.2) were still commonly used at the time of that CVE disclosure. 

​

What’s the takeaway? If you are a Java customer using Spring Beans, chances are, you’re using a vulnerable version. However, unlike Log4j which was trivial to exploit in nearly all circumstances, the Spring vulnerability is not exploitable unless a number of conditions are also met (outlined in our blog post). So even though the Spring vulnerability affects more customers overall, Log4j was more susceptible to mass exploitation. 

What should I do now? 

While log4j was a “drop everything and patch now” type of event, we can take a more measured approach with the Spring vulnerability. If your application does not meet all the conditions to be exploitable, you should still plan to patch soon – as you should for any vulnerable library – but you do not need to do so immediately. 

We also advise the use of Veracode Software Composition Analysis. With Veracode SCA, you can quickly verify whether an application portfolio that you’re scanning with us contains the library needed to be affected by either of these vulnerabilities. 

If you are an existing Veracode customer but do not have SCA, please contact your Veracode representative for more information on a 10-day courtesy license.  

For the latest information on the Spring Framework vulnerability, please check out our blog,  
Spring Framework Remote Code Execution (CVE-2022-22965).  For the latest information on Log4j vulnerability, please bookmark our resources page.